I cannot see that allowing OPTION to unitise dimensions would "restrict"
users.

Whilst I'd be happy to join you in a Microsoft bashing session, I don't see
why this capability should be referred to as Microsoft dictatorship type
tactics, for example look at the W3C standard for SVG+CSS (a 2 dimensional
vector web presentation standard) that allows optional dimensional
specifications for lengths and positions etc.    This standard has little to
do with Microsoft (they've ignored it!); and it simply allows the
specification of two-dimensional layout (optionally) in a user friendly or
"real world" form (albeit pixels, in, mm and cm etc).



Whilst I agree with the concept include unit files being theoretically
equivalent as long as the conversion relationships are correctly expressed,
the reality will be that people would implement these themselves to
differing degrees of accuracy and this would introduce errors, which cannot
be quantified.   For example, supposing someone accidentally defined 1in =
2.51cm instead of 2.54 or just defined it as 2.5.   In addition the choice
of baseline (i.e. which real world unit corresponds to a POV unit of 1)
inch, mm or km in the inc file may also introduce errors due to
multiplication rounding and potentially differences due to arithmetic
precision.   In essence it cannot be escaped that it would in practise lead
to unnecessary differences.  It would be better to standardise based on a
built in POV facility or approved installed include file.     Whilst I know
that this will also add fuel to the fire, the other main problem comes from
the fact that textures etc would also need unitising.



Aside from this, my argument still stands - without any encouragement of
unitisation from a built in facility, the majority of POV scene files will
not use units and neither will the textures utilised by them and because of
this POV objects will not be portable without at least some effort.    I
also maintain that they are less readable.  Whilst I agree that the effort
is hopefully be minimal to port objects, it is less friendly!



If the whole world is moving forward in terms of standards such as XML, SVG,
VRML, etc, it seems a shame that I cannot even cut and paste a simple object
from one file to another and it not work!   Not because of the
implementation I might add, but because the standard does not even allow a
means for it to work.

"Chambers" <bdc### [at] junocom> wrote in message
news:3f4beb60@news.povray.org...
>
> "Patrick Elliott" <sha### [at] hotmailcom> wrote in message
> news:MPG.19b57896a4efe84198987c@news.povray.org...
> > Actually.. It might be nice to have such a definition built in,
>
> No, it wouldn't.  It would unnecessarily restrict the users.  The POV Team
> is NOT Microsoft.
>
> As it is, ABX is right.  Assuming they are written correctly, using *any*
> units.inc file and interchanging them will work without a hitch.  I even
> wrote one that allows you to define the actual unit size for inch, which
all
> others are based off of.
>
> Ie, (pseudocode follows)
>
> If inch is not defined,
>     inch = 1/12
>
> foot = inch*12
> yard = foot*3
> mile = foot*5280
>
> etc
>
> So you could scale them to fit objects which have not been unitized.
>
> ...Chambers
>
>

Post a reply to this message